No-Op Packets
The Device can send No-Op packets to verify Real-Time Transport Protocol (RTP) and T.38 connectivity, and to keep NAT bindings and Firewall pinholes open.
The Device can send No-Op packets in RTP and T.38 formats:
|
■
|
RTP No-Op: The RTP No-Op support complies with IETF Internet-Draft draft-wing-avt-rtp-noop-03 ("A No-Op Payload Format for RTP"). The IETF document defines a No-Op payload format for RTP. The draft defines the RTP payload type as dynamic. You can configure the payload type as described in the following procedure (default is 120). |
|
■
|
T.38 No-Op: T.38 No-Op packets are sent only while a T.38 session is activated. Sent packets are a duplication of the previously sent frame (including duplication of the sequence number). |
|
➢
|
To configure No-Op packet feature: |
|
1.
|
Enable the feature, using the [NoOpEnable] parameter. You can also enable this feature per IP Profile, using the 'Generate No-Op Packets' parameter (see Configuring IP Profiles). |
|
2.
|
Configure the interval between each No-Op packet sent by the Device during the silence period (i.e., no RTP or T.38 traffic), using the [NoOpInterval] parameter. |
|
3.
|
For RTP No-Op packets, configure the payload type of the No-Op packets, using the [RTPNoOpPayloadType] parameter. |
|
●
|
The Device always accepts incoming No-Op packets. |
|
●
|
Use the Device’s No‑Op Packet feature when it communicates with another AudioCodes Device. You must configure the [RTPNoOpPayloadType] parameter to the same value on both devices to ensure proper No-Op packet handling.
|
If the Device uses the No‑Op feature with a non‑AudioCodes endpoint, the endpoint may not recognize No‑Op packets because no SDP negotiation occurs. As a result, the endpoint may discard these packets.